[SPARK-52409][SDP] Only use PipelineRunEventBuffer in tests #51352
+29
−41
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@jonmio – I'm not sure how to add you as a reviewer, but heads up about this PR. |
|
Merged to master |
asl3
pushed a commit
to asl3/spark
that referenced
this pull request
Jul 14, 2025
### What changes were proposed in this pull request? This PR inverts the relationship between event callbacks and `PipelineRunEventBuffer`. Prior to this PR: - `PipelineUpdateContext` had a `PipelineRunEventBuffer`, that all events from the run were written to. - This `PipelineRunEventBuffer` contained an `eventCallback` val which the Connect backend used to forward events to the client - The only code that reads from the buffer is test code After this PR: - `PipelineUpdateContext` has an `eventCallback`, which is invoked on all events. - The test harness constructs a `PipelineRunEventBuffer` and passes its `addEvent` method to the `eventCallback` ### Why are the changes needed? With the prior code, there was a risk of memory pressure from the event buffer for long-running pipelines. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Existing tests ### Was this patch authored or co-authored using generative AI tooling? No This patch had conflicts when merged, resolved by Committer: Sandy Ryza <sandy.ryza@databricks.com> Closes apache#51352 from sryza/pipeline-run-event-buffer. Lead-authored-by: Sandy Ryza <sandyryza@gmail.com> Co-authored-by: Sandy Ryza <sandy.ryza@databricks.com> Signed-off-by: Sandy Ryza <sandy.ryza@databricks.com>
ksbeyer
pushed a commit
to ksbeyer/spark
that referenced
this pull request
Jul 14, 2025
### What changes were proposed in this pull request? This PR inverts the relationship between event callbacks and `PipelineRunEventBuffer`. Prior to this PR: - `PipelineUpdateContext` had a `PipelineRunEventBuffer`, that all events from the run were written to. - This `PipelineRunEventBuffer` contained an `eventCallback` val which the Connect backend used to forward events to the client - The only code that reads from the buffer is test code After this PR: - `PipelineUpdateContext` has an `eventCallback`, which is invoked on all events. - The test harness constructs a `PipelineRunEventBuffer` and passes its `addEvent` method to the `eventCallback` ### Why are the changes needed? With the prior code, there was a risk of memory pressure from the event buffer for long-running pipelines. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Existing tests ### Was this patch authored or co-authored using generative AI tooling? No This patch had conflicts when merged, resolved by Committer: Sandy Ryza <sandy.ryza@databricks.com> Closes apache#51352 from sryza/pipeline-run-event-buffer. Lead-authored-by: Sandy Ryza <sandyryza@gmail.com> Co-authored-by: Sandy Ryza <sandy.ryza@databricks.com> Signed-off-by: Sandy Ryza <sandy.ryza@databricks.com>
haoyangeng-db
pushed a commit
to haoyangeng-db/apache-spark
that referenced
this pull request
Jul 22, 2025
### What changes were proposed in this pull request? This PR inverts the relationship between event callbacks and `PipelineRunEventBuffer`. Prior to this PR: - `PipelineUpdateContext` had a `PipelineRunEventBuffer`, that all events from the run were written to. - This `PipelineRunEventBuffer` contained an `eventCallback` val which the Connect backend used to forward events to the client - The only code that reads from the buffer is test code After this PR: - `PipelineUpdateContext` has an `eventCallback`, which is invoked on all events. - The test harness constructs a `PipelineRunEventBuffer` and passes its `addEvent` method to the `eventCallback` ### Why are the changes needed? With the prior code, there was a risk of memory pressure from the event buffer for long-running pipelines. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Existing tests ### Was this patch authored or co-authored using generative AI tooling? No This patch had conflicts when merged, resolved by Committer: Sandy Ryza <sandy.ryza@databricks.com> Closes apache#51352 from sryza/pipeline-run-event-buffer. Lead-authored-by: Sandy Ryza <sandyryza@gmail.com> Co-authored-by: Sandy Ryza <sandy.ryza@databricks.com> Signed-off-by: Sandy Ryza <sandy.ryza@databricks.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
This PR inverts the relationship between event callbacks and
PipelineRunEventBuffer.Prior to this PR:
PipelineUpdateContexthad aPipelineRunEventBuffer, that all events from the run were written to.PipelineRunEventBuffercontained aneventCallbackval which the Connect backend used to forward events to the clientAfter this PR:
PipelineUpdateContexthas aneventCallback, which is invoked on all events.PipelineRunEventBufferand passes itsaddEventmethod to theeventCallbackWhy are the changes needed?
With the prior code, there was a risk of memory pressure from the event buffer for long-running pipelines.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing tests
Was this patch authored or co-authored using generative AI tooling?
No